Chapter 3. Compressed Frame Types / 3章 圧縮フレーム種類

There are only two types of frames in VP8.
　VP8にフレームの種類は二つしかない．

Intraframes (also called key frames and, in MPEG terminology, I-frames) are decoded without reference to any other frame in a sequence, that is, the decompressor reconstructs such frames beginning from its “default” state. Key frames provide random access (or seeking) points in a video stream.

　イントラフレーム（キーフレームとも呼ばれ，MPEG用語ではIフレームである）はシーケンス内のいかなる他のフレームを参照することなく復号される．つなわち，復号器は初期状態から始めてもこのようなフレームを再構成する．キーフレームは動画像のランダムアクセス（もしくは早送り）を提供する．

Interframes (also called prediction frames and, in MPEG terminology, P-frames) are encoded with reference to prior frames, specifically all prior frames up to and including the most recent key frame. Generally speaking, the correct decoding of an interframe depends on the correct decoding of the most recent key frame and all ensuing frames. Consequently, the decoding algorithm is not tolerant of dropped frames: In an environment in which frames may be dropped or corrupted, correct decoding will not be possible until a key frame is correctly received.

　インターフレーム（予測フレームとも呼ばれ，MPEG用語ではPフレーム）は先行するフレームを参照して符号化され，特に全ての先行フレームから最も近いキーフレームも含まれる．一般的に，インターフレームの正確な復号は，最も近いキーフレームと全ての後続フレームが正しく復号されていることに依存する．したがって，復号アルゴリズムはフレーム落ちへの堅牢性はない．フレームが欠落や劣化するような環境において，キーフレームが正しく受信されるまで，正しい復号はできないだろう．

In contrast to MPEG, there is no use of bidirectional prediction. No frame is predicted using frames temporally subsequent to it; there is no analog to an MPEG B-frame.

　MPEGと比較して，双方向予測は存在しない．いかなるフレームも時間的に連続されるフレーム群を用いて予測されることはない．MPEGのBフレームに相当するものは存在しない．

Secondly, VP8 augments these notions with that of alternate prediction frames, called golden frames and altref frames (alternative reference frames). Blocks in an interframe may be predicted using blocks in the immediately previous frame as well as the most recent golden frame or altref frame. Every key frame is automatically golden and altref, and any interframe may optionally replace the most recent golden or altref frame.

　第二に，VP8は代替予測フレームという概念が追加されている．これはゴールデンフレームや代替参照フレームと呼ばれている．インターフレーム内のブロック群は直前フレームと同様に最も近いゴールデンフレーム，または代替参照フレームに含まれるブロックを用いて予測されるだろう．すべてのキーフレームは自動的にゴールデンかつ代替参照フレームとなり，あらゆるインターフレームは状況に応じて最も近いゴールデン，または代替参照フレームに置き換えられるかもしれない．

Golden frames and altref frames may also be used to partially overcome the intolerance to dropped frames discussed above: If a compressor is configured to code golden frames only with reference to the prior golden frame (and key frame) then the “substream” of key and golden frames may be decoded regardless of loss of other interframes. Roughly speaking, the implementation requires (on the compressor side) that golden frames subsume and recode any context updates effected by the intervening interframes. A typical application of this approach is video conferencing, in which retransmission of a prior golden frame and/or a delay in playback until receipt of the next golden frame is preferable to a larger retransmit and/or delay until the next key frame.

　ゴールデンフレームと代替参照フレームは上記で説明したフレーム欠落に対する不耐性を部分的に克服するかもしれない．もし符号化器が先行するゴールデンフレーム（そしてキーフレーム）のみを参照するように符号化するように設定されていると，キーフレームとゴールデンフレームの副ストリームは他のインターフレームの欠落に影響されることなく復号されるかもしれない．おおざっぱに言って，（符号化器側における）この実装は，ゴールデンフレームがインターフレーム間による影響を受けるコンテキストの更新を包含し，かつ再符号化することを要求している．この方針の典型的な応用例はテレビ会議であり，再生において次のゴールデンフレーム受信までの再送や遅延は，次のキーフレーム受信までの大きな再送もしくは遅延よりも好ましい．

Chapter 2: Format Overview / 2章：フォーマット概要

VP8 works exclusively with an 8-bit YUV 4:2:0 image format. In this format, each 8-bit pixel in the two chroma planes (U and V) corresponds positionally to a 2x2 block of 8-bit luma pixels in the Y plane; coordinates of the upper left corner of the Y block are of course exactly twice the coordinates of the corresponding chroma pixels. When we refer to pixels or pixel distances without specifying a plane, we are implicitly referring to the Y plane or to the complete image, both of which have the same (full) resolution.

　　VP8は8bit YUV 4:2:0形式の画像のみで動く．この形式において，二つの色差画像（UとV）に含まれているそれぞれ8bitの画素は，輝度画像（Y）に含まれる2x2ブロックの8bit画素に対応している．輝度ブロックの左上のコーナー座標値は色差画素の座標値のちょうど2倍になっている．もしどの画像か限定することなく画素群もしくは画素距離について言及する場合，輝度画像もしくは完全なカラー画像を暗に言及している．両者の画像は同じ（フル）解像度を有している．

As is usually the case, the pixels are simply a large array of bytes stored in rows from top to bottom, each row being stored from left to right. This “left to right” then “top to bottom” raster-scan order is reflected in the layout of the compressed data as well.

　　たいていの場合，画素群は行方向に上から下へ，それぞれの行は左から右に，格納された単純に巨大なバイト配列である．この「左から右へ」，そして「上から下へ」というラスタスキャン順は圧縮されたデータにも同様に反映されている．

Provision has been made for the support of two different YUV color formats in the VP8 bitstream header, however only one format is supported in the first release of VP8.

　　ProvisionはVP8ビットストリームのヘッダにおいて二つの異なるYUVカラー画像形式をサポートするために作られている．しかしながら，VP8の初期リリースではひとつの形式のみがサポートされている．

The YUV formats differ in terms of their conversion to and from RGB color space. The first corresponds to the traditional YUV color space similar to the YCrCb color space defined in ITU-R BT.601. The second (currently unsupported) format corresponds to a new YUV color space whose digital conversion to and from RGB can be implemented without multiplications and divides. The VP8 Decoder should decode and pass the information on to the processes that convert the YUV output to RGB color space.

　　YUV形式はRGB色空間との変換という観点から本質的に異なる．第一は，ITU-R BT.601で定義されているYCｂCr色空間に似て，古くからあるYUV色空間に対応していることである．第二に（現状サポートされていないが），乗算と除算を使わずにRGB空間との完全なディジタル変換が実装可能な新しいYUV色空間に対応していることである．VP8デコーダはYUV出力をRGB色空間に変換する処理へこれらの情報を復号し，かつ使えなければならない．
　　
Occasionally, at very low datarates, a compression system may decide to reduce the resolution of the input signal to facilitate efficient compression. The VP8 data format supports this via optional upscaling of its internal reconstruction buffer prior to output (this is completely distinct from the optional postprocessing discussed earlier, which has nothing to do with decoding per se). This upsampling restores the video frames to their original resolution. In other words, the compression/decompression system can be viewed as a “black box”, where the input and output is always at a given resolution. The compressor might decide to “cheat” and process the signal at a lower resolution. In that case, the decompressor needs the ability to restore the signal to its original resolution.

　　ごくまれに，非常に低ビットレートのとき，圧縮システムは効果的な圧縮を即するために入力信号の解像度を削減決定をするかもしれない．VP8データフォーマットは出力の前に内部再構成バッファの中でオプションのアップスケーリングを用いてこの機能をサポートしている（これは先に述べたオプションの事後処理とは完全に異なる物である．事後処理は復号処理に何ら影響を与えない）．このアップサンプリングは動画像フレームを原画像解像度に復元する．言い換えると，符号化/復号システムはブラックボックスのように見える．ここで，入力と出力ははつねに与えられた解像度である．圧縮器はチートすることを決定し低解像度で信号を処理するかもしれない．この場合，復号器はその信号を元解像度に復元する機能が必要となる．

Internally, VP8 decomposes each output frame into an array of macroblocks. A macroblock is a square array of pixels whose Y dimensions are 16x16 and whose U and V dimensions are 8x8. Macroblock-level data in a compressed frame occurs (and must be processed) in a raster order similar to that of the pixels comprising the frame.

　　内部的に，VP8はそれぞれの出力フレームをマクロブロック行列に分割する．マクロブロックは画素の正方行列であり，輝度画像は16x16で色差画像は8x8である．圧縮されたフレーム内のマクロブロックデータは，フレームを構成する画素の並びと同様に，ラスタスキャン順に生じる（かつ，処理される）．

Macroblocks are further decomposed into 4x4 subblocks. Every macroblock has 16 Y subblocks, 4 U subblocks, and 4 V subblocks. Any subblock-level data (and processing of such data) again occurs in raster order, this time in raster order within the containing macroblock. As discussed in further detail below, data can be specified at the levels of both macroblocks and their subblocks.

　　マクロブロック群はさらに4x4のサブブロック群に分割される．すべてのマクロブロックは16個の輝度サブブロック，4個の色差Uサブブロック，4個の色差Vサブブロックを所有している．任意のサブブロックデータ（およびこれらの処理）もまたラスタスキャン順に発生する．この時，ラスタスキャン順はマクロブロック内である．以下でより詳しく述べるように，データはマクロブロックとサブブロックのレベルで言及される．

Pixels are always treated, at a minimum, at the level of subblocks, which may be thought of as the “atoms” of the VP8 algorithm. In particular, the 2x2 chroma blocks corresponding to 4x4 Y subblocks are never treated explicitly in the data format or in the algorithm specification.

　　画素群は常に，少なくとも，サブブロックレベルで処理される．このサブブロックはVP8アルゴリズムのアトムとして考えられるだろう．特に，4x4輝度サブブロックに対応する2x2色差ブロックは決してデータフォーマットやアルゴリズム規定文で陽に扱われることはない．

The DCT and WHT always operate at a 4x4 resolution. The DCT is used for the 16Y, 4U and 4V subblocks. The WHT is used (with some but not all prediction modes) to encode a 4x4 array comprising the average intensities of the 16 Y subblocks of a macroblock. These average intensities are, up to a constant normalization factor, nothing more that the zeroth DCT coefficients of the Y subblocks. This “higher-level” WHT is a substitute for the explicit specification of those coefficients, in exactly the same way as the DCT of a subblock substitutes for the specification of the pixel values comprising the subblock. We consider this 4x4 array as a second-order subblock called Y2, and think of a macroblock as containing 24 “real” subblocks and, sometimes, a 25th “virtual” subblock. This is dealt with further in Chapter 13.

　　DCTとWHTは常に4x4解像度で扱われる．DCTは16個の輝度，4個のUV色差サブブロックで使われる．WHTはマクロブロックの16個輝度サブブロックの平均濃度を構成する4x4行列を符号化するために使われる（全てではないがいくつかの予測モードにおいても使われる）．これら平均濃度は，定数である正規化係数に至るまで，輝度サブブロックのゼロ番目のDCT係数以上のものではない．この高レベルWHTは，これら係数の陽な定義の代わりとなる．サブブロックのDCTがサブブロックから構成される画素値の定義の代わりとなるのと正に同じ道筋である．この4x4行列を2次サブブロックY2として考え，マクロブロックは24個の実サブブロックを含んでおり，時々25番目の仮想サブブロックを含んでいると考える．これは13章で取り扱う．

The frame layout used by the reference decoder may be found in the file yv12config.h

　　参照復号器に使われているフレームレイアウトはyv12config.hの中で見いだされる．

Chapter 1: Introduction / 1章 はじめに

This document describes the VP8 compressed video data format created by Google On2, together with a discussion of the decoding procedure for this format. It is intended to be used in conjunction with and as a guide to the reference decoder provided by Google On2. If there are any conflicts between this document and the reference source code, the reference source code should be considered correct. The bitstream is defined by the reference source code and not this document.
本稿はGoogle On2によって作られたVP8圧縮動画像のデータ形式について記述する．また，このデータ形式のデコード処理についても議論する．Google On2によって提供される参照デコードソフトと強調し，かつ道案内となることが意図されている．もし本稿と参照ソフトウェアのコードの間になんならの矛盾があれば，参照ソフトウェアのコードが正しいと考えるべきである．ビットストリームは参照ソフトウェアのコードによって定義されているのであって，本稿によって定義されているのではない．

Like many modern video compression schemes, VP8 is based on decomposition of frames into square subblocks of pixels, prediction of such subblocks using previously constructed blocks, and adjustment of such predictions (as well as synthesis of unpredicted blocks) using a discrete cosine transform (hereafter abbreviated as DCT). In one special case, however, VP8 uses a “Walsh-Hadamard” (hereafter abbreviated as WHT) transform instead of a DCT.
近頃の多くの動画像圧縮方式のように，VP8はフレームをピクセル群からなる正方形の小ブロックへの分解し，事前に再構築されたブロック群をもちいて小ブロックの予測し，離散コサイン変換（以下ではDCTと記述する）を用いて予測したブロック（非予測ブロックの合成も同様である）の整合性をとる，という手法を基本としている．しかしながら，ある特別な場合にVP8はウォルシュ・アダマール変換（以下ではWHTと記述する）をDCTの代わりに用いる．

Roughly speaking, such systems reduce datarate by exploiting the temporal and spatial coherence of most video signals. It is more efficient to specify the location of a visually similar portion of a prior frame than it is to specify pixel values. The frequency segregation provided by the DCT and WHT facilitate the exploitation of both spatial coherence in the original signal and the tolerance of the human visual system to moderate losses of fidelity in the reconstituted signal.
概要としては，このような仕組みは大部分の動画像信号にある時間と空間の一貫性を利用してビットレートを削減する．時間的に前のフレームにおいて視覚的に似ている部分の位置を特定することは，画素値を特定するよりも効果的である．DCTやWHTにより規定される周波数分割は，原信号の空間的な一貫性と再構成信号における忠実性の欠落を緩和するために人間の視覚システムの寛容さを利用することを促進する．

VP8 augments these basic concepts with, among other things, sophisticated usage of contextual probabilities. The result is a significant reduction in datarate at a given quality.
VP8はコンテキスト確率の洗練された活用と共にこれら基本コンセプトや他のことも改良する．その結果，指定された品質において著しくビットレートが削減される．

Unlike some similar schemes (the older MPEG formats, for example), VP8 specifies exact values for reconstructed pixels. Specifically, the specification for the DCT and WHT portions of the reconstruction does not allow for any “drift” caused by truncation of fractions. Rather, the algorithm is specified using fixedprecision integer operations exclusively. This greatly facilitates the verification of the correctness of a decoder implementation as well as avoiding difficult-to-predict visual incongruities between such implementations.
いくつかの同様な仕組み（例えば昔のMPEG形式）とは異なり，VP8は再構成画素の正確な値群を記述する．とりわけ，再構成におけるDCTとWHT部分の記述は，分数の切り捨てに起因するいかなる「ドリフト」も許容しない．より正確に言うと，このアルゴリズムは固定精度整数演算の排他的な利用により特徴付けられている．このことは，デコーダ実装の正確さの検証を促進すると共に，複数の実装における視覚的な不一致の予測困難性を排除している．

It should be remarked that, in a complete video playback system, the displayed frames may or may not be identical to the reconstructed frames. Many systems apply a final level of filtering (commonly referred to as postprocessing) to the reconstructed frames prior to viewing. Such postprocessing has no effect on the decoding and reconstruction of subsequent frames (which are predicted using the completely-specified reconstructed frames) and is beyond the scope of this document. In practice, the nature and extent of this sort of postprocessing is dependent on both the taste of the user and on the computational facilities of the playback environment.
完璧な動画像再生システムにおいて，表示されたフレームが再構成されたフレームであると同定出来るかもしれないし出来ないかもしれない，ということを強調しておく．多くのシステムは表示の前に再構成されたフレームに最終段のフィルタを適用する（一般的に事後処理として言及される）．このような事後処理は後続フレーム（これらは完全に定義された再構成フレームを用いて予測される）のデコード処理と再構成処理になんら影響を与ず，本稿の対象外である．実際，この類の事後処理の本質と限界は，利用者の嗜好と再生環境の計算能力の両方に依存している．

VP8のビットストリーム仕様書を翻訳したよ（1章）

ざっくり翻訳してみたので晒してみる．こんな変な日本語読むぐらいなら，素直に英語のまま理解した方が早そうです……．でもまぁ何かの助けになれば．

仕様書よりも実装が正しいらしいｗ　古いMPEGとの違いは，DCT処理における厳密性で，いかなるドリフトも許容しないらしい．

先週のTwitter（抜粋）

• 15:08 久方ぶりに研究室に来た 相変わらず後輩は来ていない……なんなの？外部の人を交えた今日の打ち合わせ忘れていないか不安なり
• 16:07 @hylom 知ってるよｗｗ こんな手の込んだ弁当を作る余裕はないですよｗｗ いつも同じサンドウィッチ
• 16:09 なんかインタレースがちらちらしていて，見にくいよ #SonLive
• 16:51 このタイミングで風邪をひいたのが辛い……ノド痛いし怠いしどうすんの？
• 16:58 そんなわけで，これから打ち合わせ！
• 08:00 NHKの天気予報でBGMが流れるようになってる！
• 18:15 最後のゼミ終了ー やっぱり詰められたorz いや，私が悪いので仕方ない
• 13:48 昼飯を何食うのか考えるのが億劫　だから毎日同じモノを食っているわけだが，今日は準備ゼロ　何食おう……
• 16:41 家計簿の整理が終わった　クレジット関係でどうにも帳尻が合わないけど，年度末なので無理矢理合わせた　転載する手間を何とか軽減できないなものか……
• 21:15 1日中先送りにしてた今日締め切りの作文なう　さくさく終わらせて寝ないとな
• 22:46 近年まれに見る酷い出来だ……だが，寝ないと　無念
• 10:03 入社式なう
• 23:44 忘れないうちにメモ：え，社会になんか夢みてんじゃないの？大丈夫？というメルヘンな新入社員代表の挨拶だった　私の分は代表されていない気がする
• 23:45 IE6って葬式に出したはずだよね　私は参列していないけど……けど，目の前にあるこれは何？
• 23:47 「自分からすすんで練習するグループ」と「いわれたから渋々練習するグループ」どちらが上達すると思う？と質問しておいて前者しかいないことを確認して満足する所長　でも，研修スタイルは後者　はぁ？
• 23:48 グループ面談と称して，リーダーがひたすらしゃべる面談　それなんて接待？というか，自分たちの設定した趣旨を理解してます？
• 23:50 集合写真で，役員の前後左右を女性で固めるってどんな時代錯誤？せめて，身長順（健康診断済み）にしたらたまたま女性が前の方に集まってしまいました体とかとれないのだろうか？
• 23:51 ルールとして，エレベータ内でプライベートも含めてケータイメールをしてはいけません(キリッ ちょ，おま
• 23:52 指示を出す人は，出すべき指示が遅いだけで無能だと思われてしまう　というか，遅かった……意外な盲点
• 23:53 起立・礼・着席　をなんども練習させるのは良いのだが，その意義とか意味とか深く理解して指示を出しているのだろうか？はなはだ疑問
• 00:03 まだあったな　仕事できない人は気配りもできないんですね，年齢とか関係なく　わかりにくい列を作って延々と並ばせておいて，フォローなしとか酷いよ
• 00:04 そうか，原稿読まないといけないような人だから，貴社の質問にわからないとか今後検討するとか，残念なコメントしか返せないのね……って，大丈夫か？
• 00:04 貴社じゃなくて，記者だ　しっかししてくれATOKよ
• 00:06 女性が抑揚のなくマイク越しでしゃべり続けていた　これを聴かされていると，ヒステリーを聴いているようで憂鬱になる
• 00:07 標準ソフトウェアで縛ることによる，サポートコスト削減と，仕事の能率低下　どちらが大きいのだろうか
• 00:07 よし，寝ます……
• 19:06 帰宅なう　なんか面倒になってきたので同期飲みをスルーしてきた　オフィシャルは来週あるのでいいっしょ
• 19:07 ツンデレGLというあだ名がついていた　私じゃないよ，ヒステリーな人ね
• 21:03 私はもっとしゃべりたい！語りたい！　うわっ，なんて面倒そうな人なんだ……
• 10:38 ようやく業務ケータイのマニュアルを読み終わった　ガラケーはマニュアル分厚すぎ
• 10:51 RSS読んでて，エイプリルフールネタにまんまとだまされた＞＜　やるなあの社員！
• 11:16 本はiPadに勝つが、書棚は勝てない。　http://business.nikkeibp.co.jp/article/life/20100401/213774/
• 11:22 オチがいまいちだけど，我々がiPadを得ることで失うものが存在する，という話は面白い　さっきと同じhttp://business.nikkeibp.co.jp/article/life/20100401/213774/
• 22:23 今日の花見のことをすっかり忘れていた……まぁいいか　先日の代々木公園と千鳥ヶ淵で満足したし
• 22:24 東のエデン　劇場版Iを見てた　エデンはTV版までが面白かった　ん，それってなんてエヴァ？
• 06:41 お，ようやくshiftキーが押されっぱなしになる原因がわかった……HHKが壊れてる　OSのバグだと思っていたんだが，ちがったよorz
• 07:19 薄桜鬼が意外ときつい……桑島さんの声だけを救いに見続ける
• 10:57 ラブプラスのためにiPhoneを買うかどうか真剣に悩みそうになった

先週のTwitter（抜粋）

• 11:18 むむむ，Mathemticaのpasswordが発行されない……どこかで見落としたか？
• 20:34 卒論の本文は非公開のことが多いよな そういうのを学会発表の参考文献に挙げられても困るというか，指導してねーなというか まぁいいか
• 20:52 昼飯を久しぶりに外食したら，食べ過ぎていまだにお腹がすかない……今夜は夕食抜きでいいや
• 21:06 他人の好きなものを覚えているほど甲斐性のある方じゃないんだが……今回はたまたま「良いな」と思ったものが相手にマッチしただけ これからも期待されると困るというか，応えられないというか
• 10:15 珍しく変なコラムだ グーグルこそ「コピーライトに対する遵法意識はきわめて低い」ことをしてきたと思う 中国国民をネットユーザと読み替えても全く違和感がないし http://blog.tatsuru.com/2010/03/24_0728.php
• 11:36 10〜20年ぐらい前の文献を見てるんだが，昔の人はすごいなぁ 結構力業で目的を完遂している
• 12:49 雑誌1年分の解体終了 さすがに以前5年分もやったことがあるので，手慣れたものだなｗｗ
• 13:25 Safariの設計かWindowsの設計，どっちかが腐ってる……ネットつなぎに行くとレスポンスが悪くなる上に，周辺機器のIOまで遅くなる LANも周辺機器ではありますが……
• 13:53 6ppmでスキャンしているんだが，一体いつ終わるんだろうか……
• 14:37 エアコンのクリーニングが始まった それなのに研究室で作業を続けるうちらってどんだけなんだｗｗ
• 18:35 んー，意外と時間がかかる というかそれは分かっていたことではあるんだが 今日は2000ページぐらいスキャンした気がする その後処理にマシンパワーが足りんｗ
• 13:58 紙を切り刻むのに飽きた……ADFがあっても紙を刻むのは人手
• 15:47 本棚から溢れる本を整理して，30冊ぐらい街の図書館に寄贈してきたなう　ブックオフで50円とか100円つけられるよりもよっぽど気持ちがよい
• 16:00 NAVERのお花見があるのかｗｗ　日曜日体調が良ければ参加しようー＞http://atnd.org/events/3783
• 16:09 学会会場となっている大学の教室で，電源を無断借用するのはもしかして窃盗なのか？そういう発想はなかったんだが倫理的にはそういうものかもしれないような　http://techon.nikkeibp.co.jp/article/TOPCOL/20100326/181357/
• 17:38 おー，そういうことか　近所でヘリを5機ほど目撃して，さらにそのまま旋回を始めたので何事かと思っていたら＞竹下通りでパニック
• 18:52 鳥肉を繊維に沿って薄くスライスしたら，面白い食感になった　おいしい！
• 10:55 おはようございます　昨夜飲み屋でdisられまくった　曰く，部屋が殺風景すぎてヤル気になれないよね，とかなんとか
• 15:03 花見参加中！ #naver_hanami
• 16:45 . @naver_jp @pick_staff 代々木公園から歩いて帰宅なう　お花見の企画ありがとうございました！楽しかったデス
• 16:46 お花見参加者の皆様，ありがとうございました〜 #naver_hanami
• 17:10 のどに痛みを感じる　これはもしや……風邪？

学会誌の自炊方法

信学会の学会誌はいまだに電子的に入手できないので，とりあえずスキャンして破棄している．というわけで，スキャン手順をメモしておく．

解像度は高いし8bppだしで，閲覧には向かない．ホントは適切な2値化をしてJBIG2で圧縮すればかなり小さくなるはずなんだが．それは今後の課題．

1. 雑誌を解体する
   1. 半分の厚さにして，裁断機に入るようにする
   2. ノドを切り落として全てのページをばらばらにする
   3. 表紙，目次，写真ページ，本文に分ける
   4. 表紙のノド側にはのりが付いていることが多いので，カッターで削り取る
2. スキャンする
   1. ADFに突っ込んでスキャンする
   2. 条件は600dpi，24bpp（カラー画像）　このときA4だと4960x7016画素になる
3. 画像処理
   1. ガンマ値をいじって（今回は1.2），しきい値（今回は192）以上の白を背景として白を飛ばす
   2. グレースケールのものは8bppにして，カラーのものは24bppのままにする
   3. 4800x6900画素になるように，周辺を切り落とす(80,58,4880,6958)
   4. 閲覧しやすいようにサムネイルを作っておく