投稿者: Sarah

携帯は、最新機種でも16ビットカラー(65536色)表示の機種が多く、グラデーションのような階調のある画像で色むらが起きます。

　
左:PCでの見た目(32bit)　右:携帯での見え方(16bit：イメージ)

これは減色でパターンディザをかけると目立ちません。
photoshopの場合、[Web用に保存]から[PNG-8]、または[GIF]を選択し、[ディザアルゴリズムの指定]を[パターン]にします。
色数はグラデーションがなめらかに見えるぎりぎりまで減色します。

30色に減色してパターンディザをかけたもの(16bit：イメージ)

VGA端末のQVGAモードでディザのドットが見えることがありますが、それでも減色した方がきれいです。

Flashで画像を置く際の最適化のポイントとして
「複雑で面積の小さなものはビットマップで、単純で面積の大きい図形はパスで」
というのは良く聞かれますが、その面積のボーダーラインを正確に把握していなかったので実験してみた。

この画像で大きさを変えながら検証。使ったFlaファイルはこちら。

以下、FlashCS3、DeviceCentralCS3＋プロファイルW52Kでのテスト結果

		26x26px	76x76px	180x180px	240x240px
パス (Flash上での曲線数：360)	Heapメモリ	145KB	152KB	155KB	156KB
	ファイルサイズ	1KB	1.1KB	1.4KB	1.5KB
PNG-24 (Photoshop「Web用に保存」)	Heapメモリ	108KB	130KB	238KB	340KB
	ファイルサイズ	0.5KB	2.4KB	7KB	10.4KB
PNG-8　16色 (PNG-24→Pngquant→OptiPNG)	Heapメモリ	107KB	113KB	142KB	169KB
	ファイルサイズ	0.4KB	1.6KB	4.6KB	6.6KB

おおよそこんな感じのまとめ。
　・アイコンのような要素はビットマップ画像が向いている
　・背景にあたるような要素はパスが向いている
　・どちらとも言えない大きさの画像の場合、メモリ重視ならビットマップ、ファイルサイズ重視ならパス
　・VGA端末向けのデータの場合、パスを使用した方が良い場面が多い
　・QVGA端末向けのデータの場合、ビットマップ画像を使用した方が良い場面が多い

なお、この結果はパスの曲線数や複雑さ、ビットマップ画像にした際は色数に左右されます。

　・サンプルファイルよりパスの曲線数が多い場合
　　…ビットマップにした方が良い場合が増える

　・サンプルファイルよりビットマップ画像の色数が多い場合や画像が複雑な場合
　・またはビットマップ画像としてJPEG形式の画像を使用する場合
　　…パスにした方が良い場合が増える

適宜読み替えて、どちらを使ったら良いかの判断の目安にしてください。
迷ったら両方作って比較するのが一番。

個人的には
・PNGを減色すると消費メモリもかなり大きく落ちる
・明らかにビットマップの方が良い面積と、明らかにパスの方が良い面積の中間にあるグレーゾーンがとても広い
の2点が「ここまで大きく出るのか、、」という感想。

Flashでは同一のパーツを使い回すことでファイルサイズを減らしたり、制作過程を効率化することができます。
以下は、できるだけファイルサイズを増やさずに見た目のバリエーションを作るための方法です。

(1)インスタンスに明度/着色/アルファ/詳細を設定し、カラーバリエーションを作る

インスタンスを選択した状態で[プロパティ]パネルの[カラー]の欄から色をつけることができます。
はじめは[なし]に設定されています。

・明度…プラスに設定すると明るく、マイナスに設定すると暗くなります。
・着色…指定した1色で塗りつぶします。塗りつぶしの濃さを設定できます。
・アルファ…透明度を調整します。0%で完全に透明になります。

[詳細]は色調の変更を行う時や、着色とアルファの効果を同時に適用する時に使います。
[詳細]を選択後、[設定…]ボタンをクリックするとカラー設定のためのダイアログが出てきます。
赤、緑、青のそれぞれの値が色調、アルファの値が透明度に影響します。

(2)共通部分のある画像は使いまわし、差分はレイヤで重ねる

例えば、白馬とシマウマが並んでいるようなイラストの場合では、
「白馬」と「シマウマ」で別々のシンボルを用意するよりも
「白馬」と「シマだけ」のシンボルを用意し、2つのシンボルをFlash上で重ね合わせる方がデータが少なくて済みます。

「人A」「人B」「人C」を描く場合にも、
・「顔シンボルA＋髪型シンボルA」
・「顔シンボルB＋髪型シンボルB」
・「顔シンボルA＋髪型シンボルB」
のようにパーツを使いまわすことで、ファイルサイズを膨らませずにバリエーションを作れます。

(3)変形・斜形・反転を使用する

インスタンスに変形をかけることで、共通のシンボルを使用できる場合があります。
例)真正面から見た蝶のイラストのような、対象の画像の場合
…半分だけの蝶のシンボルを作り2つ配置、片方を反転させます。
例)同じ形の花びらが5つ並んだ桜のような画像の場合
…1枚の花びらをシンボル化し、コピーしたものを回転させて配置します。

(4)テクスチャやパターン画像は塗りに指定して敷き詰める

テクスチャの当たっている部分や、水玉模様などの繰り返しのある画像の場合、シェイプの塗りにシームレスパターン(並べてもつなぎ目の見えない画像)を指定することで軽量化できます。

1.photoshopなどでシームレス画像を作成
2.Flashにドラッグ＆ドロップし、ライブラリに登録する
3.ステージ上にシェイプを作成する
4.[カラー]パネルでタイプを[ビットマップ]に変更、サムネイルからシームレス画像を選択

以上の手順で、シェイプの塗りに画像を隙間なく敷き詰めることができます。
敷き詰めた画像が歪んだりズレが発生した場合は、シェイプを基準点右下でシンボル化してください。

補足など

・複数組み合わせて活用するといい感じ
例えば以下のような手順では、Flash上でパターンのカラーバリエーションを作れます。
1.透過PNGで作ったシームレスパターンをシェイプの塗りに指定
2.[カラー]で色のバリエーションをつける
3.下に敷くシェイプの色との組み合わせで複数カラーバリエーション作成

・(4)を除く(1)～(3)の手法は、制作のスピードアップやファイルサイズの軽量化には役立ちますが、携帯での再生時にメモリを食うことがあるため注意してください。

就活の時に携帯のGUI周りを作った方とお話する機会があり、苦労話として
「有機EL液晶は焼きつきを起こしやすいので、#FFFFFFの代わりに微妙なグレーを使う」
と伺ったことがある。

ITmedia ＋D Lifestyle： au新モデル、「映像のキレイさ」はどれほどか (1/2)

> 有機ELディスプレイ自体はさほど新しい技術ではないが、液晶に比べて寿命が短く、焼き付きに弱いという弱点もあり、携帯電話への利用例はさほど多くなかった。
> 色再現性とコントラスト比以外のスペックは非公開だが、「半永久的とはいえないが、携帯電話での利用に耐えられるだけの寿命を確保することに成功」（KDDI）したほか、「焼き付きを起こさないよう、GUIや配色なども工夫した」（同）と実装のめどが立ったことから、製品への投入となったようだ。

この「配色も工夫した」のひとつが「#FFFFFFを使わない」かな？
確かに実機で標準ピクト＋白ベタ待受にすると、他の白は若干暗く見えなくもない。

MEDIASKINを2年以上使って未だ焼きついていないので、それこそプリインストールでもなければ神経質になる必要はなさそうですが。。

#MEDIASKINはブラウザのbackgroundのデフォルト色もグレーなので、透過していない画像は白い角が見えて残念なことになる

ドコモ2009年夏新機種(一部除く)から、
fscommand2(“GetBatteryLevel”);
で返ってくる電池残量の値が3段階→100段階に変更になっていました。
以下対応のためのサンプルコード。

旧機種と表示を共通化する場合(既存の待ち受けflash等の場合)

最大電池残量(MaxBatteryLevel)が100だった場合、3段階にあてはめるASを書いて共通化します。

mxbt = fscommand2("GetMaxBatteryLevel"); //電池の最大値を取得
bt = fscommand2("GetBatteryLevel"); //現在の電池残量を取得
if (mxbt == 100) { //電池の最大値が100段階だった場合
if (bt>60) {bt = 3;} //残量100～61の場合、電池残量は3とする
else if (bt>20) {bt = 2;} //残量60～21の場合、電池残量は2とする
else if (bt>0) {bt = 1;} //残量20～1の場合、電池残量は1とする
}

3段階と100段階で表示を分ける場合

MaxBatteryLevelが100だった場合と、3だった場合で条件式(if)を書いて分岐させます。
このサンプルでは、100段階の電池を20段階ずつで5つのフレームに飛ばします。

mxbt = fscommand2("GetMaxBatteryLevel"); //電池の最大値を取得
bt = fscommand2("GetBatteryLevel"); //現在の電池残量を取得
if (mxbt == 100) { //電池の最大値が100段階だった場合
if (bt>80) {gotoAndStop(2);} //残量100～81の場合、2フレーム目で停止
else if (bt>60) {gotoAndStop(3);} //残量80～61の場合、3フレーム目で停止
else if (bt>40) {gotoAndStop(4);} //残量60～41の場合、4フレーム目で停止
else if (bt>20) {gotoAndStop(5);} //残量40～21の場合、5フレーム目で停止
else if (bt>0) {gotoAndStop(6);} //残量20～1の場合、6フレーム目で停止
}
else if (mxbt == 3) { //電池の最大値が3段階だった場合
if (bt>2) {gotoAndStop(7);} //残量3の場合、7フレーム目で停止
else if (bt>1) {gotoAndStop(8);} //残量2の場合、8フレーム目で停止
else if (bt>0) {gotoAndStop(9);} //残量1の場合、9フレーム目で停止
}

アナログ時計の一周は360度です。文字盤はそれを12分割したものなので、数字の間の角度は30度です。
それを利用して、取得した時間をムービークリップの角度(_rotation)に指定することでアナログ時計を作ります。

サンプルコードは以下。
//の書いてある行はコメントとして扱われるため、このままコピー＆貼り付けして使うことができます。

//日付・時計を取得する
hour = fscommand2(“GetTimeHours”);
minutes = fscommand2(“GetTimeMinutes”);
seconds = fscommand2(“GetTimeSeconds”);

//取得した時間から針の角度を計算して代入する
xhour._rotation = hour*30+minutes*0.5;
xminutes._rotation = minutes*6;
xseconds._rotation = seconds*6;

コードをコピペしたらインスタンス名をつけます。
インスタンス名は、ムービークリップを選択した状態で「プロパティ」のパネルから設定ができます。
上のコードをそのまま使う場合、短針は「xhour」長針は「xminutes」秒針は「xseconds」としてください。

各ムービークリップの変形点が針の回転の軸になりますので、変形点は時計の中心に合わせてください。

イラレからFlashへのパスの移行には、Flash Lite 1.1の仕様上さまざまな制約があります。

(1)Flashで扱えないパスがある
以下のパスはFlash上でパスとして扱うことができません。
書き出しやAIインポート時にビットマップとして貼り付けることもできますが、
画質の調整が必要な際はphotoshopなどで保存し、画像としてFlashに配置してください。
・Illustratorの「効果」でつけられているドロップシャドウ、３D効果等
・塗りがグラデーションメッシュ

また以下のようなパスはそのままFlashにコピーすることはできませんが、アピアランスの分割や分割・拡張等を行うことによりFlashにインポートできるようになります。
・ブラシのストローク
・ブレンド
・パスの変形(パンク・膨張、歪み系など)

(2)Flash Lite 1.1の仕様上扱えないパスがある
Flash Lite 1.1では、線の拡張機能は使えません。
(線の拡張機能が使われている場合、パブリッシュ時にエラーが出ます)
flash上で線を選択し、「伸縮：標準」「線幅：丸型」「結合：丸型」にすることで回避できます。
この線のオプションは、イラレでは「線の位置：線を中央に揃える」「線端：丸型線端」「結合：ラウンド結合」にあたります。
イラレの[選択]→[共通]→[線]などを使用し、あらかじめ全ての線のオプションを変更しておくと便利。

またこの線の拡張機能はFlash 8以降の機能であるため、
Flash 8を使用できる場合は一度「名前をつけて保存」からFlash MX 2004 を選択して保存してからパブリッシュすると解決します。

移し方は、FlashCS3以降の場合はコピペでOK。
Flash8以前の場合は、イラレ上で[ファイル]→[書き出し]からswfを選択して書き出し、Flashから[ファイル]→[読み込み]でライブラリorステージに配置を選択すると配置することができます。

どちらもパスが多数グループ化された状態で配置されるためメモリを多く消費します。配置後、グループ化の解除やシンボルの分解を行ってください。

Flash Lite 1.1でビットマップ画像(GIF、JPEG、PNG画像)を配置した際に正しく配置されないバグの対処法をリストにしました。
まずこのリストの(1)～(6)を同時に試し、それでもだめなら(7)～(9)をやってみることで大抵解決できる(はず)。

(1)画像をシンボル化する
ビットマップ画像をステージに配置したら、シンボル化を行います。
シンボルのタイプをグラフィックに、基準点を右下に設定してください。

(2)画像の大きさを変更する
縦横が奇数 px の大きさの画像の場合、width、height 共に偶数 px になるよう加工します。

(3)配置位置に小数点がないか確認する
小数点があると、補間が行われるためずれが発生することがあります。

(4)縮小・拡大がされていないかを、[変形]タブで確認する
画像の拡大縮小が行われていると配置がずれてしまうことがあります。
ビットマップ画像はFlash上の変形を使わず、PhotoShop等で拡大縮小を行い
常に100％表示で配置するようにしてください。

(5)アルファトゥイーンをしている場合は透明度を変える
例えば、0％ から100％へフェードインするようなトゥイーンの場合、
1%から99％へフェードインするアニメーションに変更してください。

(6)ライブラリのビットマッププロパティでスムージングのチェックを外す

以下は、それでもダメだった場合に試してみてください。
(1)～(6)とは同時に使えない小技だったり、ヒープメモリ消費上あまりやりたくない小技です。

(7)ビットマップ画像を分解する
ビットマップ画像を分解すると、シェイプの塗りにビットマップ画像が指定された状態になります。

(8)画像の上下左右に透過で 2px くらい余裕をつけ、マスクをかける
画像の 1px ずれが直らない時は、ある程度ずれても構わないように作ります。
例えば、100 x 200px の画像を配置したかった場合、画像は102 x 202 pxで制作し、その画像の中心に100 x 200 px のシェイプを配置しマスクにします。
ズレを完全に取り除くことにはなりませんが、見た目上問題のない程度には持っていくことができます。

(9)それでもだめだった時は
Flash Lite 1.1は PC 版の Flash４ に携帯向けの拡張を行ったものであるため、
PC版 Flash４ で確認されていた不具合がそのまま残っています。
上記のチェックリストが役に立たない時や異なる不具合が発生している時は、PC向けFlash4以前の対策が有効なこともあります。

繰り返すことのできるパターン画像の場合、どのように配置するのが最も効果的か検証しました。
シェイプを置いてその塗りにビットマップを指定するのが、最もHeapメモリとファイルサイズを節約できました。

(1)静止画一枚をべた貼りする

パターンのある画像を240x432pxのPNG画像にしてべた置きしました。
メモリ消費、ファイルサイズ共に最も大きくなります。

(2)静止画を分割して並べる
パターンのある画像を絵柄の単位ごとで切り出して、並べて配置します。
このサンプルでは80x80pxのものを使用しました。

メモリ消費、ファイルサイズ共に大分良くはなりましたが、ビットマップ画像がズレるバグを回避するために一度シンボル化することを考えるとあまりすっきりしません。

(3)シェイプの塗りにパターン画像を設定する
シェイプの塗りをビットマップにし、繰り返し配置する画像を指定することで表示します。

ファイルサイズも消費メモリも最も少なく、配置も再編集も簡単。

同じ画像を10x10pxまで縮小してみると、更に消費メモリが減った

繰り返しで敷き詰められる画像は小さく軽く、シェイプの塗りに指定してください。

・配置した画像が歪む、ずれる
ビットマップ画像を配置する際、恐らくFlashPlayer4時代のものと思われるずれや歪みが発生します。
回避のしかたはこちら。→Flash Lite 1.1 で画像がずれるバグの対処法チェックリスト

・透過GIFが、Flash上で透過にならないことがある
GIF画像は保存するソフトによってヘッダ部分が異なることがあり、
Photoshop5.0等でこの現象が確認されているようです。
異なるソフトで上書きすることにより直る場合があります。

・_rotationで回転させたシンボルが徐々に小さくなる
回転時に出る小数点の処理により表示されているシンボルが小さくなります。
特にアナログ時計の秒針などで目立ちやすい現象です。
　A.[変形]タブで、全てのシンボルの表示倍率を100％にする
　B.数値入力でシンボルの位置を決めるのではなく、マウスでドラッグして位置を決める
等で解決することがあります。
それでもだめな場合は、_xscaleと_yscaleを100に設定するASを書いて
都度拡大率を100％にし直すことで対応します。

・複数枚重ねた画像やシンボルの辺に線が出る
同じ大きさの画像や、辺が重なっている部分に線が出ることがあります。
重なり合ったインスタンスを1pxずつずらす、大きさを変える、等で解決することがあります。

・複数枚重ねた画像が真っ白になる
重ねた枚数がある程度以上になると、その画像に含まれる透過が効かなくなることがあります。
画像を重ねあわせる枚数を減らしてください。

・スタック限界到達エラー
シンボルの入れ子の数が8以上になると再生ができなくなります。仕様です。
このエラーはAdobe Device Centralでも確認することができます。

・1フレーム目にASを書くと正常に実行されない場合がある
メインのタイムラインの1フレーム目に記述してあるAS(gotoAndStop()等のタイムラインコントロール系)を無視して、2フレーム目を再生してしまう場合がある。
ファイルによっては1フレーム目に書いてあっても正常に実行される場合もあり、どういった場合に発生するかは未検証。
この現象はiモードHTMLシミュレータ等のエミュレータでも確認できる。
対応策
　・1フレーム目は空けておき、2フレーム目からASを記述する(推奨)
　・空白のキーフレームだった場合、何かシェイプを置くことで正常に実行される場合がある

・画像が表示できない、取得できない
プログレッシブJPEGは機種により表示ができないため、Flash内には配置しないようにします。

(0)携帯用のパブリッシュ設定をする

携帯で再生をするためには、PCとは違う設定でパブリッシュ(swfを保存)する必要があります。
ここでは、サイズを「240x320px」パブリッシュ設定を「Flash Lite 1.1」に設定します。

(1)アクションをコピペする
fscommand2という関数を使うと、携帯の時計から数字を持ってきてflash内で使うことができます。
フレームを選択したら、「アクション」タブに以下のスクリプトをコピー＆ペーストします。

hour = fscommand2(“GetTimeHours”);
minutes = fscommand2(“GetTimeMinutes”);

☆解説
アクションスクリプトの「=」は、「代入」を意味しています。
数学で習った、「xに2を代入する」の「代入」です。
この場合、左側(hour、minutes)に、それぞれ携帯の時計で使っている数字を代入しています。

また、アクションスクリプトでは左側の文字のことを「変数」と呼びます。

(2)ダイナミックテキストで文字を配置する

まず、テキストツールを使って適当なテキストを作成します。
プロパティの[変数：]と書いてある枠の中に、先ほどアクションで使った変数(hour、minutes)を入れます。

その後、「プロパティ」左上の「静止テキスト」を「ダイナミックテキスト」に変更すると、変数に代入された数字がそのテキストの枠の中に表示されるようになります。

fscommand2は携帯専用の書き方のため、パブリッシュしたファイルをそのままパソコンで見ても時間が正しく表示されませんが、それが正常です。
表示の確認には、docomoのimodeHTMLシミュレーターか、Adobe Device Centralなどのエミュレーターを使いましょう。

ここまでのサンプルデータはこちらからダウンロードができます。

Flash CS3で 作成したFlash Lite 1.1 の swf ファイルを
Adobe Device Central で開いて heap メモリ消費量を比較してみた。
デバイスプロファイルは手元に実機のある au W52K (MEDIA SKIN) 。
携帯 Flash ではファイルサイズよりもメモリオーバーの方がよりシビアだと思う(´・ω・`)

(1) 128 色 PNG 画像 (透過あり) vs 128 色 PNG 画像 (透過なし＋マスク)
128 色に減色し、背景色を透過にした PNG 画像をそのまま配置したものと、
128 色に減色し、背景色を透過にしなかった PNG 画像にマスクをかけて
前者とほぼ同じに見えるようにしたものの比較。
時々後者の方法で納品を受けるものの、体感的な違いが少ないのでテスト。

128 色 PNG 画像(透過あり) … 143KB

128 色 PNG 画像(透過なし＋マスク) … 152KB

…微増。
マスクの曲線数はぴったり 200なので、特に複雑というほどでもなく
手間からしてもそのまま背景透過の PNG 画像を配置した方が良さそうです。

ただし、どんな画像でもそうとは限らない。次に続く。

(2) (1) から更に、圧縮を JPG にして比較してみる
JPG 画像を配置すると重くなるのは体感的にわかるけど、実際どの程度なのか。
(1) のファイルの画像のビットマッププロパティで、圧縮に JPG を使用するよう指定した。

128色 PNG 画像 (透過あり) を配置して圧縮に JPG を使用、画質 80 … 245KB

102KBも跳ね上がった。こええええ((((;゜Д゜)))
体感って数字で見るとこんなに違うのか！

128 色 PNG 画像 (透過なし＋マスク) を配置して圧縮に JPG を使用、画質 80 … 191KB

圧縮に JPG を使用するなら透過なしにマスクをした方が負担が軽い。

ここまでのビットマップ画像に関する結論：
ファイルサイズの制限にひっかからない限り PNG or GIF を利用した方が良い。
JPG を使わなければファイルサイズが厳しい場合のみ JPG を使用する。
圧縮が JPG で、透過させる必要がある場合はマスクを作って対応する。

(3)では、PNGの色数やJPGの圧縮率はメモリ消費量に影響するのか
(1) で使用した PNG 画像を減色したり、 (2) で使用した JPG 画像の圧縮率を変えることでメモリ使用量が変化するのかどうかテスト。

(1)で使用した「128 色 PNG 画像(透過あり) 」の画像を、16色まで減色 … 143KB→143KB

メモリ使用量に変化なし。

(2)で使用した「128色 PNG 画像 (透過あり) を配置して圧縮に JPG を使用、画質 80」の画像を、画質50に … 245KB → 242KB

ちょっとだけ減りましたが、この差なら画質を犠牲にしてまで圧縮する必要は無いなあ。

ビットマップ画像の画質はファイルサイズとだけ相談すれば良いようです。