こんにちわ、まつむらです。今日はソロでお送りします。
まずは告知。7月13日に、毎コミさんから「Flash プロフェッショナル・スタイル[CS3対応]」という本が出ます。いわゆる共著本で、いろんな人がFlashに関するTIPSやらなんやらを紹介する本ですが、これにまつむらも参加させていただきました。Flashを使ったキャラクターイラストとクルマのイラストの描き方やを紹介してます。
この出版に関連したイベントが7月8日、東京で開かれます。主にグラフィック関連の著者が集まってのセミナー、ディスカッション、懇親会ということで、関西からマツカサで参加しますので、よろしくです！
< https://www.c-place.ne.jp/0000engine/pec_engine.cgi?N=s070605203158
>
同じく毎コミさんの「MacFan」、今月末発売の8月号にワコムの新タブレット「Bamboo」のレビューと、ArtRageの記事を書きました。Bambooはモバイルに最適な軽量薄型ケーブル着脱可能モデルで、FAVOよりも性能がアップしてます。自分用にも先述のイベント用に買っちゃいました♪
ArtRageは改めて使ってみるとはまりますなぁ。油彩の楽しさが手軽に楽しめる、いいソフトです。
……と、なんで一人で書いているかってーと、チャットを笠居さんにすっぽかされたんですな。約束の時間に電話したら、カラオケに居てて、その店は地元なのに「うはは、帰れない」んですと(-''-;)！ アアハラガタツ...罵詈雑言書きたいところですが、オトナなので押さえてます(-''-;)
というわけで、デジクリよりカラオケが大事なカサイに本文は責任とってもらうことになり、今回まつむらは休みです〜。苦情申し立てはすべてカサイまでよろしく〜
【まつむら まきお／まんが家・イラストレーター】
starwars.comで公開されている人形アニメRobot Chickenシリーズ、トニーたけざきのガンダムマンガなみにオモロイです。
< http://www.makion.net/
> < mailto:makio@makion.net >
───────────────────────────────────
ども、笠居です。とりあえずは、告知であります。
MKほか、豪華執筆陣が執筆に参加して（野中氏曰く：共著者数は、最近減少傾向にあるモーニング娘。の人数より多い）、鋭意制作中であります「Flash プロフェッショナル・スタイル」という書籍が、ようやく7月に出版されます（予定）。
で、その本の出版に絡め、来る7月8日にセミナーがありまして、MKもそこで、自分たちが本に書いた内容について、色々としゃべることになっております。
< https://www.c-place.ne.jp/0000engine/pec_engine.cgi?N=s070605203158
>
店頭発売前に書籍を手に入れられるという特典もついてますし、セミナー後に交流会などもあるようなので、お時間とお財布に余裕のある方（笑）は、ぜひ足を運んでいただけると幸いであります。
さて、今回は、わたくし笠居の極私的な都合で、まつむらさんとのチャットができなかったので（ごめんなさいm(__)m）、その代わりになるかどうかはわかりませんが、JPEGについて「専門的すぎる」話をちょっと書いてみることにしました。正直、知っていたからといってものすごく役に立つ話でもありませんし、長くなるので、興味のない方は読み飛ばしてください。
まずは告知。7月13日に、毎コミさんから「Flash プロフェッショナル・スタイル[CS3対応]」という本が出ます。いわゆる共著本で、いろんな人がFlashに関するTIPSやらなんやらを紹介する本ですが、これにまつむらも参加させていただきました。Flashを使ったキャラクターイラストとクルマのイラストの描き方やを紹介してます。この出版に関連したイベントが7月8日、東京で開かれます。主にグラフィック関連の著者が集まってのセミナー、ディスカッション、懇親会ということで、関西からマツカサで参加しますので、よろしくです！
< https://www.c-place.ne.jp/0000engine/pec_engine.cgi?N=s070605203158
>
同じく毎コミさんの「MacFan」、今月末発売の8月号にワコムの新タブレット「Bamboo」のレビューと、ArtRageの記事を書きました。Bambooはモバイルに最適な軽量薄型ケーブル着脱可能モデルで、FAVOよりも性能がアップしてます。自分用にも先述のイベント用に買っちゃいました♪ArtRageは改めて使ってみるとはまりますなぁ。油彩の楽しさが手軽に楽しめる、いいソフトです。……と、なんで一人で書いているかってーと、チャットを笠居さんにすっぽかされたんですな。約束の時間に電話したら、カラオケに居てて、その店は地元なのに「うはは、帰れない」んですと(-''-;)！ アアハラガタツ...罵詈雑言書きたいところですが、オトナなので押さえてます(-''-;)
というわけで、デジクリよりカラオケが大事なカサイに本文は責任とってもらうことになり、今回まつむらは休みです〜。苦情申し立てはすべてカサイまでよろしく〜
【まつむら まきお／まんが家・イラストレーター】
starwars.comで公開されている人形アニメRobot Chickenシリーズ、トニーたけざきのガンダムマンガなみにオモロイです。
< http://www.makion.net/
> < mailto:makio@makion.net >
───────────────────────────────────
ども、笠居です。とりあえずは、告知であります。
MKほか、豪華執筆陣が執筆に参加して（野中氏曰く：共著者数は、最近減少傾向にあるモーニング娘。の人数より多い）、鋭意制作中であります「Flash プロフェッショナル・スタイル」という書籍が、ようやく7月に出版されます（予定）。
で、その本の出版に絡め、来る7月8日にセミナーがありまして、MKもそこで、自分たちが本に書いた内容について、色々としゃべることになっております。
< https://www.c-place.ne.jp/0000engine/pec_engine.cgi?N=s070605203158
>
店頭発売前に書籍を手に入れられるという特典もついてますし、セミナー後に交流会などもあるようなので、お時間とお財布に余裕のある方（笑）は、ぜひ足を運んでいただけると幸いであります。
さて、今回は、わたくし笠居の極私的な都合で、まつむらさんとのチャットができなかったので（ごめんなさいm(__)m）、その代わりになるかどうかはわかりませんが、JPEGについて「専門的すぎる」話をちょっと書いてみることにしました。正直、知っていたからといってものすごく役に立つ話でもありませんし、長くなるので、興味のない方は読み飛ばしてください。
●JPEGってなんだろな
まず、JPEGという圧縮方式（JPEGというのはファイルフォーマットではなく、圧縮方式の名前です）が、どういった仕組みなのかをお話しします。
JPEGにはlossless（非損失）なオプションもありますが、これはlossyな（損失のある）JPEGとは全くアルゴリズムを異にするものである上に、この方式を実装しているツールも一般的にはおそらくないと思われますので、ここではごく一般的な、lossyな圧縮方式であるJPEGについての話を進めていきたいと思います。
JPEG圧縮におけるデータの損失ですが、これには「計算精度上の損失」と「圧縮過程での意図的な損失」の二つがあります。元々lossyであることが前提ですから、誤差が小さな範囲に収まるような「計算精度上の損失」はあまり気にされませんが、この「計算精度上の損失」というものは、数値処理のライブラリや、ソースコードやコンパイラが違うと異なった結果を導きます。
そして、これは画像のJPEG化（エンコード）だけでなくJPEGを画素に転換（デコード）する際にも発生しています。つまり、同じJPEG圧縮されたファイルを別々のツールで表示した場合、結果は完全に同じにはならないということなんです。
では、この「計算精度上の損失」はなぜ起こるのでしょうか。それにはJPEGの記録方式を知る必要があります。JPEGは、DCT（離散コサイン変換）という方式を使って記録するのですが、そう言われてもわかりませんよね（笑）。
イメージとして説明すると、平面状にならんでいる画素を一列に並べ直して、各画素の値を棒グラフにしたものを考えてみてください。そこには一種の波形が描かれますよね。この波形をコサイン波の重ね合せで表現する（一種の周波数解析に相当する）ような処理がDCTです。で、JPEGでは画素を記録する代わりに、このコサイン波の各項の係数を記録します（エンコード）。この係数のデータを受け取って、逆の計算をすれば元の画素が得られるわけです（デコード）。
いま「逆の計算をすれば元の画素が得られる」と書きましたが、じつは正確に元の値が得られるわけではありません。コサイン波を扱うということは、小数点以下を含む実数で数値計算をすることになるわけですが、実際に求めたい画素データは整数です。つまり、変換計算の過程のどこかで「数値を丸める（切り捨て・切り上げ・四捨五入などですね）」必要があるわけで、これが「計算精度上の損失」にあたります。
このちょっとした数値の丸め方や、有効桁数の大小が結果に違いを与えます。そして、JPEGではこの処理がエンコードするときだけでなく、デコードする時にも必要になります。ですから、異なるツールを使えば結果も異なります。また、同じツールであっても、エンコード時とデコード時の計算結果が一致する、という保証もありません。それがJPEGというものの仕様なのです。
さて、ここまでで計算精度上の損失については、ご理解いただけたかと思います。がしかし、これだけでは画素の値をコサイン波の係数に置き換えたというだけで「圧縮」したことになりません。
ではどうするかというと、画質に影響の少ない（人間の目に判別しにくい）コサイン波項の係数を、さらに丸めたり、あるいは削除することでデータサイズを圧縮します。この部分の処理がDCTを使ったJPEGの圧縮のかなめになる部分で、どの程度削るかで圧縮率とクォリティが変化します。これが「圧縮過程での意図的な損失」ですね。
で、この「影響の少ないコサイン波項」ですが、これはJPEGエンコーダがその都度その都度、最も影響の少ないものから選び出して処理をしている、というわけではありません。ただ機械的に「量子化テーブル」という数値表を使って処理をしているだけです。DCTは、そんな機械的処理でも良い結果が出しやすい性質を持っているので、この方法が使われているのですが、この量子化テーブルにしても、ツールによって細部が異なる設定がされていると考えるべきで、先に書いた「ツールが違えば結果も違う」が助長されることになるわけです。
で、上記のような処理はJPEGでは8×8の矩形プロックごとに行われています。圧縮率を上げすぎる（係数を削りすぎる）と、ひとつのブロック内ではオリジナルと似たような傾向のものが復元できていたとしても、隣のブロックとの境界では、その差が目立つことがあるわけで、これがJPEGのブロックノイズと呼ばれるものです。
以上のような仕様であることから、JPEGは、フラットな色面の多い画像の圧縮が苦手（ブロック内に同じ色しかないと圧縮時にデータを丸めたり削ったりしにくい）であり、色の濃淡の境目にノイズが出やすい（係数変換のときの誤差が大きい）という特性を持つことになる、と僕は理解しています。
最後になりますが、これらの知識はすべて僕が独自に調べたわけではなく、ほとんどがNiftyのグラフィックフォーラム時代に、会議室で教わったことです。そのとき教えてくれた方たちに感謝します。
でわでわ
【笠居 トシヒロ／WEBコンテンツクリエイター・デザイナー】
風邪引いたと思ってたら、気管支炎でした。はよ治ってくれぃ(/_;)
< http://www.mad-c.com/
> < mailto:kasai@mad-c.com >
まず、JPEGという圧縮方式（JPEGというのはファイルフォーマットではなく、圧縮方式の名前です）が、どういった仕組みなのかをお話しします。
JPEGにはlossless（非損失）なオプションもありますが、これはlossyな（損失のある）JPEGとは全くアルゴリズムを異にするものである上に、この方式を実装しているツールも一般的にはおそらくないと思われますので、ここではごく一般的な、lossyな圧縮方式であるJPEGについての話を進めていきたいと思います。
JPEG圧縮におけるデータの損失ですが、これには「計算精度上の損失」と「圧縮過程での意図的な損失」の二つがあります。元々lossyであることが前提ですから、誤差が小さな範囲に収まるような「計算精度上の損失」はあまり気にされませんが、この「計算精度上の損失」というものは、数値処理のライブラリや、ソースコードやコンパイラが違うと異なった結果を導きます。
そして、これは画像のJPEG化（エンコード）だけでなくJPEGを画素に転換（デコード）する際にも発生しています。つまり、同じJPEG圧縮されたファイルを別々のツールで表示した場合、結果は完全に同じにはならないということなんです。
では、この「計算精度上の損失」はなぜ起こるのでしょうか。それにはJPEGの記録方式を知る必要があります。JPEGは、DCT（離散コサイン変換）という方式を使って記録するのですが、そう言われてもわかりませんよね（笑）。
イメージとして説明すると、平面状にならんでいる画素を一列に並べ直して、各画素の値を棒グラフにしたものを考えてみてください。そこには一種の波形が描かれますよね。この波形をコサイン波の重ね合せで表現する（一種の周波数解析に相当する）ような処理がDCTです。で、JPEGでは画素を記録する代わりに、このコサイン波の各項の係数を記録します（エンコード）。この係数のデータを受け取って、逆の計算をすれば元の画素が得られるわけです（デコード）。
いま「逆の計算をすれば元の画素が得られる」と書きましたが、じつは正確に元の値が得られるわけではありません。コサイン波を扱うということは、小数点以下を含む実数で数値計算をすることになるわけですが、実際に求めたい画素データは整数です。つまり、変換計算の過程のどこかで「数値を丸める（切り捨て・切り上げ・四捨五入などですね）」必要があるわけで、これが「計算精度上の損失」にあたります。
このちょっとした数値の丸め方や、有効桁数の大小が結果に違いを与えます。そして、JPEGではこの処理がエンコードするときだけでなく、デコードする時にも必要になります。ですから、異なるツールを使えば結果も異なります。また、同じツールであっても、エンコード時とデコード時の計算結果が一致する、という保証もありません。それがJPEGというものの仕様なのです。
さて、ここまでで計算精度上の損失については、ご理解いただけたかと思います。がしかし、これだけでは画素の値をコサイン波の係数に置き換えたというだけで「圧縮」したことになりません。
ではどうするかというと、画質に影響の少ない（人間の目に判別しにくい）コサイン波項の係数を、さらに丸めたり、あるいは削除することでデータサイズを圧縮します。この部分の処理がDCTを使ったJPEGの圧縮のかなめになる部分で、どの程度削るかで圧縮率とクォリティが変化します。これが「圧縮過程での意図的な損失」ですね。
で、この「影響の少ないコサイン波項」ですが、これはJPEGエンコーダがその都度その都度、最も影響の少ないものから選び出して処理をしている、というわけではありません。ただ機械的に「量子化テーブル」という数値表を使って処理をしているだけです。DCTは、そんな機械的処理でも良い結果が出しやすい性質を持っているので、この方法が使われているのですが、この量子化テーブルにしても、ツールによって細部が異なる設定がされていると考えるべきで、先に書いた「ツールが違えば結果も違う」が助長されることになるわけです。
で、上記のような処理はJPEGでは8×8の矩形プロックごとに行われています。圧縮率を上げすぎる（係数を削りすぎる）と、ひとつのブロック内ではオリジナルと似たような傾向のものが復元できていたとしても、隣のブロックとの境界では、その差が目立つことがあるわけで、これがJPEGのブロックノイズと呼ばれるものです。
以上のような仕様であることから、JPEGは、フラットな色面の多い画像の圧縮が苦手（ブロック内に同じ色しかないと圧縮時にデータを丸めたり削ったりしにくい）であり、色の濃淡の境目にノイズが出やすい（係数変換のときの誤差が大きい）という特性を持つことになる、と僕は理解しています。
最後になりますが、これらの知識はすべて僕が独自に調べたわけではなく、ほとんどがNiftyのグラフィックフォーラム時代に、会議室で教わったことです。そのとき教えてくれた方たちに感謝します。
でわでわ
【笠居 トシヒロ／WEBコンテンツクリエイター・デザイナー】
風邪引いたと思ってたら、気管支炎でした。はよ治ってくれぃ(/_;)
< http://www.mad-c.com/
> < mailto:kasai@mad-c.com >
- WACOM Bamboo MTE-450/K0
- ワコム 2007-05-18
- おすすめ平均
使い勝手は良いが高周波の異音あり
こんなタブレットを待っていました！
by G-Tools , 2007/06/20